Skip to content

Comments

Fix DEX freeze bug#92

Open
masihyeganeh wants to merge 1 commit intomasterfrom
fix-DEX-freeze-bug
Open

Fix DEX freeze bug#92
masihyeganeh wants to merge 1 commit intomasterfrom
fix-DEX-freeze-bug

Conversation

@masihyeganeh
Copy link
Contributor

@masihyeganeh masihyeganeh commented Feb 23, 2026

Description

Reviewers checklist:

  • Try to write more meaningful comments with clear actions to be taken.
  • Nit-picking should be unblocking. Focus on core issues.

Authors checklist

  • Provide a concise and meaningful description
  • Review the code yourself first, before making the PR.
  • Annotate your PR in places that require explanation.
  • Think and try to split the PR to smaller PR if it is big.

This change is Reviewable

@masihyeganeh masihyeganeh requested a review from a team as a code owner February 23, 2026 11:37
@masihyeganeh masihyeganeh requested review from TxCorpi0x, metalarm10, miladz68 and ysv and removed request for a team February 23, 2026 11:37
Copy link
Contributor

@ysv ysv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ysv reviewed 3 files and all commit messages, and made 3 comments.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on masihyeganeh, metalarm10, miladz68, and TxCorpi0x).


integration-tests/modules/dex_test.go line 3058 at r1 (raw file):

// via raw bank keeper. This test asserts the fix: the second order (which would
// lock frozen tokens) must be rejected.
func TestFrozenTokenEscapeViaDEX(t *testing.T) {

are these 2 tests from immunify bugreport ?

they are almost equal so I would keep 1 one of them. Either integration or keeper test


x/asset/ft/keeper/keeper_dex.go line 69 at r1 (raw file):

	for _, send := range actions.Send {
		// Validate frozen balances before sending to prevent transferring frozen tokens

does this part of code run during order execution ?

As far as I remember our plan was to make sure that if order is inside orderbook it will be guaranteed executable when matched. And I think this check brakes such logic

Lets discuss


integration-tests/modules/dex_test.go line 3230 at r1 (raw file):

		placeOrder2,
	)
	requireT.Error(err, "Second order of 400,000 must fail: it would lock frozen tokens; available spendable is 0")

maybe it makes sense to check that address is not able to lock 100k or 10k also.
Smaller portion of frozen/locked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants